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REMARKS/ARGUMENTS 

A Final Office Action was mailed in this matter on 1 1/17/05. On 12/19/05 Applicants 
filed a Response to the 1 1/17/05 Office Action. On 3/28/06 the undersigned spoke with 
Examiner Gart regarding the status of the case. Examiner Gart indicated that he had recently 
been assigned responsibility for the handling of the present application. During the course of the 
conversation with Examiner Gart proposed amendments to the claims were discussed, and on 
3/28/06 a draft of the proposed amendment was faxed to Examiner Gart. On 4/5/06 the 
undersigned and Examiner Gart briefly discussed the 3/28/06 draft proposed amendment. The 
Examiner indicated that at the present time, particularly given the short amount of time that he 
has been assigned to the case, he was going to issue an Advisory Action, maintaining the Final 
Rejection set forth in the 1 1/1 7/05 Office Action. The Examiner's courtesy during the course of 
the telephone conversations was much appreciated. 

The 12/19/05 Response filed by the Applicants canceled claims 1-7, without prejudice to 
subsequently pursuing such claims through continued prosecution, and left claims 21 and 23-27 
pending in the application. This present response amends claim 21, as shown above. 

Independent Claim 21 has been rejected under 32 USC 102(e) as being anticipated by US 
5,870,717 (Wiecha) . In the 4/10/06 Advisory Action, the Examiner notes: 

Wiecha does disclose a system comprising a PLURALITY of first end-user computer systems 
geographically distributed throughout the enterprise comprising a user interface and the ability to 
access disk storage on a shadow catalog server (Wiecha: column 16, lines 23-28). 
4/1 0/06 Office Action, p. 2. 

A review of Wiecha shows that there are numerous references to a "shadow catalog 
server". The references cited in the 4/10/06 Office Action to a shadow catalog server are 
actually from claim 1 of Wiecha (at column 16: lines 23-28 of Wiecha). 

It is noted that that there are many other references to a shadow server in the Wiecha 
reference. For example col. 8: lines 8-23 of Wiecha provides additional discussion for the 
shadow catalog server of Wiecha, and Fig. 12-2 of Wiecha shows a shadow server in connection 
with other elements of the system. 

According to Wiecha: 

[2.] .A "shadow catalog server", 331 (FIG. 12-2) with disk storage that can be accessed 
over a LAN by one or more end-users' computers, the disk storage being used to hold one or more 
electronic catalogs 328 and program code 331 to enable browsing of the catalog and transmitting 
purchase orders to the "buyer master server" 324; 
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[3.] A "master buyer server" 324 (FIG. 12-3), which is a computer system within the 
enteiprise containing (1) program code (described below) which can take purchase orders 332 
from one or more end-user computers and control their flow through the enterprise's business 
processes, as described under "Workflow" below, before transmitting them over a network to the 
supplier via the Maintenance Entity 320 and (2) a to a Purchase Order data base 322 that can be 
accessed over a LAN 326." 

Wiecha col. 8: lines 8-23. 

It appears clear from a reading of Wiecha that the shadow catalog server holds 
information for one or more electronic catalogs, along with program code with allows a user to 
browse the catalogs and transmit purchase orders. The purchase orders are transmitted to a 
master buyer server. However, it appears to be very clear that there is no provision for the 
transmission, or duplication of customer purchase order information from one shadow catalog 
server to another shadow catalog server. It is respectfully that this is one significant aspect of the 
pending claim 21 which appears to be clearly lacking in Wiecha. 
Specifically, as amended claim 21 recites in part: 

providing a plurality of customer facing utility systems which are configured to receive 
customer transaction requests, wherein the customer transaction requests include customer orders 
to buy or sell securities; 
Claim 2 1 , further recites: 

providing a plurality of sets of customer facing data, wherein each set of customer facing 
data has a corresponding customer facing utility system; 

wherein each set of customer facing data includes a first type of data which can be 
written to by its corresponding customer facing utility system, and a second type of data which is 
provided by the firm side system, and the second type of data cannot be written to by the 
corresponding customer facing utility system, and a third type of data which is provided by the 
street side utility systems, and the third type of data cannot be written to by the corresponding 
customer facing utility system; 
Claims 21 further recites: 

writing said transaction record to a first set of customer facing data of the plurality of sets 
of customer facing data sets, wherein the transaction record is of the first type of data of the first 
set of customer facing data; 

replicating said transaction record to each of the plurality sets of customer facing data; 

The above quoted language of claim 21 recites an operation which is distinct from the operation 
of Wiecha in many respects. Initially it should be noted that claim 21 provides for a plurality of 
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customer facing utility systems. Claim 21 further provides that each of the customer facing 
utility systems is provided with a set of corresponding customer facing data. Each of these 
plurality of sets of customer facing data includes three different types of data. Additionally, 
claim 21 provides that a transaction request is written to a first set of customer facing, and the 
transaction record is then replicated to the other sets of the plurality of sets of customer facing 
data. Thus, in operation for example, if a customer were to access a system through a customer 
facing utility system, and place a transaction request, a transaction request record would then be 
written as a first type of data in the first set of customer facing data. This transaction request 
record would then be replicated in each the other sets of customer facing data. Additionally, the 
transaction request would be forwarded to the street systems as recited in claim 21 above. 

It is respectfully submitted that nothing in Wiecha appears to provide for, among other 
things, any suggestion of providing multiple shadow catalog servers, then replication of customer 
transaction request records, such that when a customer transaction request is generated, it is then 
replicated across all sets of customer facing data. Indeed, it appears that Wiecha provides an 
operation whereby the shadow catalog stores data for multiple catalogs, and provides program 
code which allows a user to transmit purchase orders to master buyer computer. It is respectfully 
submitted that this operation does not suggest that the customer order information would 
replicated across multiple sets of customer facing data. 

Additionally, it should be noted that claim 21 also recites: 

providing a plurality of sets of street side facing data, wherein each set of street side 

facing data has a corresponding street side utility system; 

wherein each set of street side facing data includes a first type of data which is provided 

by the firm side utility system, and the first type of data cannot be written to by the corresponding 

street side utility system, and a second type of data which can be written to by its corresponding 

street side utility system; 

Claim 21 further recites: 

executing said transaction request at a first street side utility system; 
creating a record of said transaction execution; 

writing said transaction execution record to a first set of street side facing data which 
corresponds to the fist street side utility system, wherein the record of said transaction is of the 
second type of data of the first set of street side facing data; and, 
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replicating said transaction execution record to each of the plurality of sets of customer 
facing data, such that said transaction execution record is replicated in the third type of data for 
each of the plurality of sets of customer facing data. 

Thus, claim 21 provides that for each transaction record, the street side utility which executes 
the transaction, writes the transaction execution record to its corresponding set of street side 
facing data, and then the transaction execution record is replicated in the third type of data for 
each of the plurality of sets of customer facing data. It is respectfully submitted that this 
operation of providing for the replicating of transaction execution records to each the plurality of 
sets of customer facing data, is yet another element of claim 21 which does not appear to be 
disclosed or suggested by claim Wiecha. Thus, in light of the above it is submitted that claim 21 
is patentable over the references. Further, it is respectfully submitted that claims 23-27 depend 
from claim 21, and such they are patentable for at least the same reasons as claim 21. 

Conclusion 

For the reasons set forth above, it is believed that all claims present in this application are 
patentably distinguished over the references. Therefore, reconsideration is respectfully 
requested, and it is requested that this application be passed to allowance. 

The Commissioner is hereby authorized to charge any deficiency in the fees filed, 
asserted to be filed or which should have been filed herewith (or with any paper hereafter 
filed in this application by this firm) to our Deposit Account No. 50-2001 under Order 
No. SCHB-3600 . A duplicate copy of the transmittal cover sheet attached to this 
Response is provided. 


Respectfully submitted, 

FARELLA BRAUN + MARTEL LLP 
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